feat: semi-additive measures - #2502

If this is just a parent-column protected dimension (e.g., it's not the fully qualified node name like v3.order_details.order_date but just order_date), then it validates cleanly here but fails at query time:

POST /nodes/metric/
{"query": "SELECT SUM(line_total) FROM v3.order_details",
 "reaggregate": {"rules": [{"dimension": "order_date", "fn": "last_value"}]}}
  -> 201, status: valid

GET /sql/metrics/v3/?metrics=v3.balance&dimensions=v3.product.category
  -> 422 "Reference `order_date` is not fully qualified. Use the `node.column` form..."

Should this just reject a non-fully-qualified name (and I think the UI might need to change based on that as well)?

This is related to the above comment -- here it's not producing fully qualified column names, just the column name itself, but then those metrics will fail to generate sql.

Hmm, does this make distinct counts additive? For example let's say base_metrics is grouped by (date_id, category, week) and the outer query
collapses date_id away. If we have this setup:

The change here will return SUM(visitor_count) which isn't the distinct visitor count. The removed code here had a special case for Aggregability.LIMITED with COUNT(DISTINCT grain_col).

To be fair I think the old form was broken too, since base_metrics projects visitor_count and not customer_id, so COUNT(DISTINCT base_metrics.customer_id) referenced a missing column and would have errored.

Since this is in a path unrelated to semi-additive measures... could it be split out? We can have a separate PR that addresses this issue with its own tests.

Hmm, it looks like a filter on the protected dimension will make the metric additive?

For example if we test with the same metric (v3.daily_balance) + dimension but with and without a filter:

correct metrics=[v3.daily_balance] + dimensions=[v3.product.category]

WITH
v3_order_details AS (
SELECT  o.order_date,
      oi.product_id,
      oi.quantity * oi.unit_price AS line_total
 FROM default.v3.orders o JOIN default.v3.order_items oi ON o.order_id = oi.order_id
),
v3_product AS (
SELECT  product_id,
      category
 FROM default.v3.products
),
order_details_0 AS (
SELECT  t2.category,
      t1.order_date date_id_order,
      SUM(t1.line_total) line_total_sum_e1f61696
 FROM v3_order_details t1 LEFT OUTER JOIN v3_product t2 ON t1.product_id = t2.product_id
 GROUP BY  t2.category, t1.order_date
)

SELECT  order_details_0.category AS category,
      MAX_BY(order_details_0.line_total_sum_e1f61696, order_details_0.date_id_order) AS daily_balance
 FROM order_details_0
 GROUP BY  order_details_0.category

incorrect metrics=[v3.daily_balance] + dimensions=[v3.product.category] + filters=["v3.date.date_id[order] >= 20260101"]

-- order_date disappears from the CTE's GROUP BY and MAX_BY becomes SUM
WITH
v3_order_details AS (
SELECT  oi.product_id,
      oi.quantity * oi.unit_price AS line_total
 FROM default.v3.orders o JOIN default.v3.order_items oi ON o.order_id = oi.order_id
 WHERE  o.order_date >= 20260101
),
v3_product AS (
SELECT  product_id,
      category
 FROM default.v3.products
),
order_details_0 AS (
SELECT  t2.category,
      SUM(t1.line_total) line_total_sum_e1f61696
 FROM v3_order_details t1 LEFT OUTER JOIN v3_product t2 ON t1.product_id = t2.product_id
 GROUP BY  t2.category
)

SELECT  order_details_0.category AS category,
      SUM(order_details_0.line_total_sum_e1f61696) AS daily_balance
 FROM order_details_0
 GROUP BY  order_details_0.category

So "daily balance by category" gives the latest balance per
category, and "daily balance by category, for January" gives the sum of every
daily balance in January, which is a different metric.

I think it does work for the cube path though, because build_synthetic_grain_group strips filter dims first.

The two frozen-measure paths (deployment vs direct metrics creation) seem to differ:

• direct metrics creation (this one) keeps the reaggregate: rule=measure.rule
• deployment strips it with rule=_frozen_measure_rule(measure.rule)

I think stripping makes more sense since the reaggregate isn't a property of the measure but rather something that can be applied on top

Should this part first call the pre-check cube_matcher._metric_graph_has_reaggregate (since it's already used in other APIs like in find_matching_cube)?

Arefn and weight used right now in sql gen or is this meant to be for later? Wonder if it's worth dropping until there's a specific use for these fields

it looks like when the protected dimension has a role and there's no alias in the registry, we'll end up falling through to SUM(metric_ref). Should this raise an "unsupported semi-additive shape" error in that case?

Instead of adding another dimension-with-role parser, can this just reuse parse_dimension_ref from construction/build_v3/dimensions.py instead?

It actually looks like there's quite a few versions of this function that got added here:

• _dimension_ref_base / _dimension_ref_role (in build_v3/decomposition.py)
• _dimension_ref_role again in (build_v3/metrics.py)
• _split_dimension_ref here
• an inline dim_ref.rsplit("[", 1) in build_v3/dimensions.py